AWSホワイトペーパー「Amazon CloudFront for Media」を斜め読みしてみた
はじめに
清水です。先日ふとしたことからAWSのホワイトペーパーに「Amazon CloudFront for Media ~ Best Practices for Streaming Media Delivery」という、Amazon CloudFrontを使ってストリーミング配信を行う際のベストプラクティス集なものが追加されていることを知りました。ホワイトペーパー自体のドキュメント履歴から、2020年11月に発行されていたようです。
- Amazon CloudFront for Media ~ Best Practices for Streaming Media Delivery
「AWSホワイトペーパーとガイド」のページから辿ることができます。（"cloudfront"などの単語で検索してみましょう。）
またAmazon CloudFront メディアストリーミングチュートリアルのページでも紹介されています。
現在は英語版しか提供されておりませんが、ざっと目を通したところストリーミング配信技術のポイントが抑えられていたり、またCloudFrontのリクエスト処理やプロトコルの最適化処理としてTCP Fast OpenやTCP輻輳制御などの技術が紹介されていました。特に後者のCloudFrontの処理技術まわりはあまりドキュメントなどでも見かけることが少なく、貴重な資料かなと個人的に思います。（「CDN features for media delivery」の「Request handling and protocol optimizations」の項目ですね。）そのほかにも全般的に、CloudFrontを使ってストリーミング配信を行う場合には一度目を通しておいたほうが良い、タイトル通りベストプラクティス集な資料です。英語版のみということできちんと全体把握することは難しいのですが、今回は翻訳ツールなどを使いながらざっとですが斜め読みしてみたので、概要をざっくりとまとめてみたいと思います。
「Amazon CloudFront for Media」を斜め読みしてみた
以下の目次で構成されています。
- Introduction
- Streaming techniques for media
- Common elements of streaming technologies
- Architecture of media workflows
- Encoding and packaging
- The origin
- The content delivery network
- Reference solutions
- CDN features for media delivery
- Architecture
- Request handling and protocol optimizations
- CloudFront configuration best practices
- Cost optimization
- CloudFront Origin Shield
- Security
- Geographical restriction
- Access control through CloudFront
- Session uniqueness
- Multi-CDN considerations
- Traffic allocation in multi-CDN environments
- Operational monitoring and reporting
- Best practices for events and service launches
- Conclusion
Streaming techniques for media
まずはメディアのためのストリーミング技術と題して、ストリーミング配信において使用される技術を解説しています。例えば、このホワイトペーパーで扱うストリーミング技術はadaptive bitrate（ABR/アダプティブビットレート/適応ビットレート）に依存していること、そしてHTTP (Hypertext Transfer Protocol)を使用していることなどを述べています。
またストリーミングのワークフローについて、VOD、ライブストリーミングそれぞれを解説しています。
Common elements of streaming technologies
ストリーミング技術に共通する要素が解説されています。これらは例えばHLS (HTTP Live Streaming)やDASH (Dynamic Adaptive Streaming over HTTP)などで実装間の違いはありますが、メカニズムとしては同等です。HTTPが使われる点、ビデオストリームが数秒間のファイルに分割される点、インデックス/マニフェストファイルから再生がはじまる点などを抑えています。
また実際のストリーミング方式である以下4つについての説明があります。特にCMAFについては、HLSやDASHに対する利点についても詳細に記述されています。
- HTTP Live Streaming (HLS)
- Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH)
- Common Media Application Format (CMAF)
- Microsoft Smooth Streaming
Architecture of media workflows
メディアワークフローにおける主要なメディアインフラストラクチャのコンポーネントとして以下を挙げています。
- ライブエンコードサービス
- VODファイルの格納
- ストリーミングオリジン
- CDN
以下は関連するAWSサービスを利用した典型的なアーキテクチャ例として紹介されています。
「Amazon CloudFront for Media」より
Encoding and packaging
異なるビットレートのストリームセットを準備するため、エンコード（ライブの場合）またはトランスコード（VODの場合）を数回並行して行う必要があります。これはABRラダーと呼ばれているそうです。このABRラダーを使ってクライアントはネットワークの状況に合わせて、ストリームを変更することができます。
エンコード後の映像は複数のストリーミングプロトコルにパッケージ化されますが、このパッケージングと保存は管理が複雑になりがちです。リアルタイムでのパッケージング（ジャストインパッケージング）が採用されるほか、広告挿入もこの段階で行われます。
ライブストリームの場合には遅延についても重要要素となります。画質を維持しながら遅延を最小に抑える必要があり、ソリューションアーキテクトはクライアントデバイスの母集団から逆算して、ニーズに合わせてストリーミング技術、ビデオ解像度、ビットレートのセットを選択する必要があります。
The origin
ストリーミング動画ファイルを提供する場所となるオリジンでは、いくつかのオプションから選択すること、もしくは特定ニーズに合わせてカスタム実装を行うことが可能です。具体的に以下が紹介されています。
- VODコンテンツのオリジンとしてAmazon S3を利用
- AWS Elemental MediaStoreは大規模ライブイベントや低遅延での利用
- AWS Elemental MediaPackageはライブとVOD両方のワーフクローに対応したジャストインタイムパッケージングを提供。複数フォーマットでのストリーミングに最も柔軟なオプションを提供
- APNパートナーではその他のオリジンソリューションを提供
The content delivery network
大量のストリームをサポートするために、スケーラブルな分散キャッシュ層が必要となります。これを実現するContent Delivery Network (CDN)を紹介しています。
Reference solutions
メディアワークフローアーキテクチャの解説の最後に、AWSソリューションライブラリで提供しているリファレンス実装を紹介しています。これらはCloudFormationテンプレートが用意されており、AWS Media Servicesをすぐに使いはじめること、またニーズに合わせてカスタマイズ、アプリケーション設計の参考にすることが可能です。
CDN features for media delivery
メディア配信のためのCDNの機能として、Amazon CloudFrontのアーキテクチャやリクエスト処理の際の最適化技法、設定の際のベストプラクティスやコスト最適化について解説がなされています。
Architecture
グローバルに広がるたくさんのエッジロケーション（5大陸40カ国以上に200以上）の紹介からはじまり、最寄りのエッジロケーションへのルーティングを説明しています。またエッジロケーションとISPなどとの接続、そしてAWSリージョンとの接続について解説しています。
またCloudFrontのアーキテクチャの紹介として、オリジンとエッジロケーションにある中間層のキャッシュ、Regional Edge Cache (REC)についても紹介があります。このRECについてはキャッシュストレージの容量が大きく、ビデオストリーミングオブジェクトの保持期間を長くすることができるとのことです。
「Amazon CloudFront for Media」より
またLambda@Edgeを使うことで、エッジロケーションでコードを実行しながらよりカスタマイズが可能なこと、その具体例の一つとして以下のリンクを挙げています。
Request handling and protocol optimizations
リクエスト処理とプロトコルの最適化として、CloudFrontでメディア配信において高いパフォーマンスを実現するための技術について説明がされています。
TCP Fast Open
TCP接続確立の際に行われる2回のラウンドトリップタイム（RTT）の遅延について、CloudFrontでは最初の接続時に設定された暗号クッキーを使用して、後続の接続を1回のRTTで確立することができるTCP Fast Open機能を有効にしているとのことです。
「Amazon CloudFront for Media」より
TLS session resumption
CloudFrontではTLSセッションを確立した後、セッションIDを使って最初のセッション作成時にネゴシエーションされたものと同じ属性でTLSセッションを再確立することが可能とのことです。このTLSセッション再開については、RFC6960にも記載があります。これによりデータ送信前のシグナリングメッセージの交換に必要なビューアとCloudFront間の往復回数を全体で4回から1回に減らすことができているとのことです。
Byte streaming
一般的なキャッシュプロキシでは、ビューアに送り返す前にオリジンからオブジェクト全体をフェッチします。しかしこの方式では余計な遅延が発生してしまい、ライブストリーミングでは望ましくありません。CloudFrontでは新たに取得したオブジェクトをオリジンから転送する際にパススルー方式を採用し、遅延を最小限に抑えています。これは、オリジンからの最初のバイトがCloudFrontに到達するとすぐに視聴者に転送されるというもので、Byte streamingと呼ばれているそうです。
Request collapsing
CloudFrontでは同じオブジェクトに同時に大量のリクエストがあり、オブジェクトがまだキャッシュに存在していない場合、単一のリクエストのみをオリジンに送りそのオブクエとを使って大量のリクエストを捌いているとのことです。（同じオブジェクト (トラフィックスパイク) の同時リクエスト ）これにより、同一のリクエストを複数回オリジンに送ることを避け、またリクエストのレイテンシが低くなるパフォマンスメリットも享受しています。
Persistent connections
CloudFrontではオリジンとのキープアライブタイムアウトの値が設定可能です。これによりオリジンとキャッシュサーバとの頻繁な接続再確立を避けることができます。（オリジンのキープアライブタイムアウト ）
TCP congestion control
2019年からCloudFrontは輻輳制御アルゴリズムとして「Bottleneck Bandwidth」と「Round-trip propagation time（BBR）」を採用しているとのことです。これにより、スループットに対して最大22%のパフォーマンス向上がなされています。これらの詳細として以下のエントリを紹介しています。
CloudFront configuration best practices
CDNのパフォーマンスならびオリジン負荷につながるキャッシュヒット率の最適化について、CloudFront開発者ガイドの推奨事項からの抜粋として案内があります。以下3点が具体的に記載されていました。
- オリジンで付与されるCache-Controlヘッダの確認
- キャッシュキーに追加するパラメータ数の削減
- キャッシュキーからのAccept-Encodingヘッダの削除
Log tail content
VODコンテンツはリクエスト頻度が時間と共に減少し、CDNキャッシュにコンテンツが存在しない状況が発生します。これはロングテールコンテンツと呼ばれます。このロングテールコンテンツでもアーキテクチャの最適化によりダイナミックコンテンツと同じようにCloudFrontアクセラレーションの恩恵を受けることが可能です。
具体的な方法として、S3がオリジンである場合はLambda@Edgeを使って最寄りのリージョンへのリクエストのルーティングを行う、オリジンがS3以外の場合ではRoute 53のレイテンシーポリシーを使う、といった方法を解説しています。
Playback errors
再生中のエラーはネットワーク条件含め様々な原因で発生し、ユーザエクスペリエンスが低下してしまいます。再生エラーを減らすためのアーキテクチャ改善方法についてまとめられています。
- 低ビットレートのストリームの提供
- CloudFrontのエラーキャッシュTTLをより低い値に設定
Cost optimization
コスト最適化として、CloudFront価格クラスの活用を挙げています。カスタマーが限られた地域内にいる場合は、高価なエッジロケーションをCloudFront設定から除外することによって配信価格を下げることができる可能性があります。
CloudFront Origin Shield
昨年2020年10月にリリースされた新機能、Regional edge cacheよりもオリジンに近い場所で働くOrigin Shieldによる負荷軽減について記されています。
「Amazon CloudFront for Media」より
Security
Geographical restriction
特定の国のユーザがコンテンツにアクセスできないようにCloudFrontで設定できるgeographical restrictionsについて解説しています。またより細かなgeo blockingの方法としてAWS WAFの利用などを紹介しています。
Access control through CloudFront
メディアコンテンツのアクセスコントロールの方法として、DRMソリューションの利用とアクセス制御ベースのアプローチの2つを紹介しています。またアクセス制御のアプローチをCloudFrontで実現する具体的な方法として、署名付きURLや署名付きCookieの機能について解説しています。
Session uniqueness
アクセス制御アプローチで利用される署名が共有されてしまうことに対するリスク対処方法がまとめられています。具体的には、署名生成の際のカスタムポリシーにソースIPを組み込むことを紹介しています。
Multi-CDN considerations
マルチCDNの利用を検討する場合の、特にデメリット面を含めての考慮事項についてまとめられています。例えばオリジン負荷の増加、運用コストの増加、アーキテクチャの追加コンポーネントの発生などです。
Traffic allocation in multi-CDN environments
マルチCDNアーキテクチャが最適であると判断した場合、トラフィック割り当てプロセスを検討する必要があります。割り当ての方法として、DNSクエリに対してCNAMEを返す方法（Route 53を利用）のほか、ビューアが再生URLを要求したときに特定のCDNを返すAPIエンドポイントをセットアップする方法を紹介しています。
Operational monitoring and reporting
運用監視のためのClodFrontで提供されるCloudWatchメトリクスについて解説しています。デフォルトのメトリクスに加えて追加のメトリクスで実現可能なことについても記載があります。より詳細に状況を調査するためのアクセスログについても解説があります。またAWSへのサポート起票時にリクエストIDなどが有用情報となること、Athenaを用いてのより細かな調査が可能なこと、さらにリアルタイムアクセスログ機能についても紹介がなされています。
Best practices for events and service launches
イベントやサービス開始時のベストプラクティスとして、AWS Infrastructure Event Management (IEM)やAWS Elemental Media Event Management (MEM)を紹介しています。どちらもAWSのサポートプログラムで、例えばMEMではプランニング、準備とテスト、イベントサポート、振り返りの4つのフェーズでイベントやサービスローンチをサポートするとのことです。
まとめ
昨年2020年11月に発行されていたAWSのホワイトペーパー「Amazon CloudFront for Media ~ Best Practices for Streaming Media Delivery」についてざっと読んでみた内容をまとめてみました。ストリーミング配信を行う上で確認しておきたい技術要素、ベストプラクティスなどがまとめられているすばらしいホワイトペーパーといえるかと思います。できれば早々に日本語版もリリースされるとありがたいなぁと思いました。
![[レポート]Amazon Redshiftで生成AIのためのデータ戦略を構築 #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
